Business Analyst Community & Resources | Modern Analyst

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

Pulkit Singhal — Sun, 25 Jan 2026 02:38:00 GMT

In a competitive and rapidly evolving financial landscape, understanding member needs is vital to maintaining strong relationships and delivering meaningful value. Yet for many institutions, especially those with legacy processes, collecting structured member feedback can be surprisingly underdeveloped. This was the case at the Federal Home Loan Bank of Chicago (FHLBank Chicago), where — despite its extensive engagement with member institutions — the Bank had never before conducted a structured, enterprise-wide Annual Member Survey.

Recognizing the need for a formalized feedback mechanism, the Bank launched an initiative to design and implement its first-ever Annual Member Survey, leveraging Salesforce as the foundational platform. As the Lead Business Analyst, I was responsible for envisioning, architecting, and orchestrating this new capability from the ground up.

This initiative ultimately became a defining example of how strategic business analysis can create net-new organizational capability, not just improve existing processes.

The Challenge: Creating a Strategic Feedback Framework from Scratch

Unlike most process-automation projects, this effort did not begin with an existing workflow to analyze or improve. Instead, the Bank faced a unique challenge:

No prior survey process existed
No historical data or response structures were available to benchmark against
No distribution, tracking, or reporting mechanisms had been established
No governance model existed for how results should be consumed
Stakeholders possessed varying assumptions about what the new survey should accomplish

This meant the project required not only systems expertise but also conceptual design, stakeholder alignment, and strategic framing.

My Role as Lead BA: Designing a New Enterprise Capability

The absence of an existing process meant that Business Analysis would shape the entire direction of the initiative. My responsibilities included defining the business problem, creating the process architecture, establishing data structures, and ensuring Salesforce could support a sustainable and scalable survey model.

1. Establishing the Vision and Framing the Purpose

Through interviews and collaborative workshops with Member Strategy, Sales, Analytics, and Leadership teams, I led discussions to answer foundational questions:

What insights should the Bank gather annually?
How should “member satisfaction” be defined in measurable terms?
What KPIs would create genuine value for leadership?
How should results be tied back to member institutions in Salesforce?

This work produced the Bank’s first Survey Vision and Strategy Framework, guiding all subsequent design decisions.

2. Building the End‑to‑End Survey Workflow in Salesforce

Because no prior workflow existed, I architected a brand‑new process designed around clarity, automation, and scalability:

Designed the survey creation and distribution model
Built logic for survey-to-member linking
Defined the response-collection data structure
Modeled the end‑to‑end visibility lifecycle, including assignment, participation, reminders, and results
Ensured dashboards would give leadership real-time insights

The process not only captured survey responses but also embedded insights directly into the Bank’s member management ecosystem.

3. Translating Ambiguity Into Clear, Actionable Requirements

Given the lack of precedent, requirements had to be derived through deep analysis rather than comparison. I authored:

Detailed user stories
Acceptance criteria
Process maps
Data models
Reporting definitions

This documentation became the foundational blueprint for developers, testers, and end-users — eliminating ambiguity and creating shared understanding.

4. Leading UAT and Validating a New Capability

Because the Bank had never conducted a survey like this, UAT required additional rigor:

I designed test scripts covering every stage of the survey lifecycle
Trained business stakeholders on how to test a process that was entirely new
Triaged defects and clarified user expectations
Ensured the system was intuitive and future-proofed

Through this, the Bank gained confidence not just in the technology, but in the process itself.

5. Supporting Rollout, Adoption, and Governance

Beyond system delivery, I worked closely with:

Member Strategy teams to formalize interpretation of results
Analytics teams to align on scoring and reporting methodologies
Change management teams to ensure smooth onboarding
Salesforce admins to embed long‑term maintainability

This ensured the survey became an annual, repeatable, institution-wide capability—not a one‑off project.

Conclusion: This project shows that Business Analysts are not just process improvers—they are capability creators.By clarifying needs, defining strategy, architecting processes, aligning teams, and ensuring quality, the BA function enabled FHLBank Chicago to establish a powerful new insight mechanism that will shape strategy for years to come.

The Annual Member Survey is now more than a project deliverable.
It is a permanent intelligence asset for the Bank — built on a foundation of Business Analysis leadership.

Business Architecture, Ontology and More with Terry Roach

Agora Insights International — Wed, 06 Mar 2024 10:40:00 GMT

It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive experience and innovative thinking. Reflecting on my conversation with Terry, I'm reminded of the importance of adaptability and innovation in our evolving professional landscape. Terry's insights, based on his extensive experience in enterprise and business architecture, provide valuable lessons for those navigating the complexities of business environments.

Background

Terry is a seasoned professional with a rich history in IT and software. He has contributed significantly to the field of enterprise architecture. His journey from working with global software vendors to pursuing a PhD in enterprise modeling illustrates a deep commitment to understanding and improving how businesses function. His work led to the founding of Capsifi, a company that initially resisted being categorized as an enterprise architecture tool, aiming instead to model business operations. Terry's shift from CEO to focusing on product vision underscores the dynamic nature of leadership and the importance of aligning roles with personal strengths and interests.

Capsifi was recently acknowledged as a Leader in the 2024 Enterprise Architecture Data Quadrant Report. This recognition reflects Capsifi's ongoing commitment to innovation, client satisfaction, and forward-thinking strategic vision.

Three Key Topics Discussed:

1. The Evolution of Business Architecture:

Business architecture is a discipline that brings a structured, disciplined approach to understanding an organization. It's about knowledge management, using frameworks like capability maps and value stream canvases to create a shared understanding of how a business operates. Terry emphasized that architecture is not just about mapping technology but understanding the essence of an organization and how it functions.

Terry's experience highlights the often-overlooked aspect of business operations within large organizations. His realization that businesses lacked a clear model to describe their functions led to the development of an enterprise ontology, which serves as a comprehensive template for understanding all business components.

2. The Role of Ontology in Business Architecture:

Ontology, the philosophical study of what exists, is crucial in creating a model of a business. Terry's academic work in this field has practical applications in business architecture, providing a structured approach to understanding the interconnectivity of various business elements.

Terry also discussed the challenge of making architecture more accessible and universally accepted across businesses. He stressed the need for tools and techniques that can be easily adopted by non-architects to facilitate collaboration and drive transformation.

3. The Future of Architecture and AI

Terry envisions a future where AI plays a significant role in business architecture. However, he emphasizes the importance of quality knowledge and creative content as the foundation for AI applications. The ability to ask meaningful questions of business models and receive insightful answers will be a key differentiator in the effectiveness of AI in architecture.

10 Learning Points:

Adaptability is essential in a world where professional roles and industries are constantly changing.
A strong foundation in business architecture can significantly improve the clarity and efficiency of business operations.
Ontologies provide a truthful framework for understanding the complex structures within an organization.
AI has the potential to revolutionize the business architecture, but it requires high-quality, context-rich knowledge to be effective.
The value stream canvas is an invaluable tool for aligning business activities with customer value.
Cross-functional collaboration and diverse perspectives are critical for successful problem-solving in modern business environments.
Technical debt and shadow systems are significant challenges that can be mitigated through proper architectural planning.
Transparency and truth in business processes foster confidence and enable continuous improvement.
The ability to communicate and share architectural models across an organization liberates the process and enhances collective understanding.
Engaging the broader business community in architectural practices can lead to more effective transformations.

Conclusion

My conversation with Terry was fun and enlightening, emphasizing the importance of staying adaptable and open to new opportunities. As Terry aptly put it,

"We should focus on being the best we can in the present moment, as the future is always in flux."

I am grateful to Terry for sharing his entrepreneurial wisdom, global experience, and valuable insights. There’s a depth of learning for each of us in our interesting and diverse career paths.

For those interested in further discussion or connecting with Terry, he is available on Linkedin and through his company, Capsifi.

I trust that you too have enjoyed the conversation. Let me know in the comments anything that resonated with you and any questions you have in mind.

Feel free to share what resonated in our Blueprints for Success Podcast or comment with any questions!

Learn more about Terry

“The CAPSICUM Framework – A semantic meta-model for strategically aligned business architecture.”

Originally a Ph.D. thesis, CAPSICUM is now a methodology, software platform & modelling repository (Jalapeno); a semantic application built on a new breed of W3C standards for semantic technologies and RDF-based ontologies.

It works, it's proven and it's saving our customers money.” - Terry Roach, Capsifi

For those interested in learning more about CAPSICUM visit Capsifi

Data Visualization Best Practices

simon.harrison@selectdistinct — Tue, 23 Jan 2024 10:44:00 GMT

This is our data visualisation best practice guide

it brings together some of our favourite tips and techniques to help you create better reports and dashboards

Data Visualisation Best Practice Contents

Have a PLAN
Know your audience
What type of dashboard?
Data Types
Use Appropriate Charts and Graphs
Make best use of space
Refine the design
Examples of Good and Bad

Dashboards are a great way to present the data your audience needs to know. But, if they done wrong, they can do more harm than good.

This best practices guide for creating dashboards walks you through the key steps to consider when designing a dashboard.

The key to a good dashboard is to make it simple yet informative. It should be easy for your audience to understand the message you’re trying to convey. And to take action on any insights or recommendations.

Its important to remember that the best dashboards are built iteratively with input and feedback from the end users

Have a PLAN

PLAN stands for Purpose, Layout, Analysis and New Release. This cycle ensures that the dashboard is fit for purpose. And continues to be as the needs of the end user may change over time

Try to follow a standard process as much as possible when introducing new dashboards

Aim for consistency with design, layout and flow of the information

Know your audience

Understand the needs of the end user.

Design the dashboard at the relevant level for that audience.

e.g. a CEO will be likely want a high level overview, whereas a HR manager will tend to be focussed on people, skills and training.

Types of Dashboards

Different Types of Data

Types of data and understanding their differences is important

This section outlines the different types of information you will need to consider and best practices for each

Categorical Data and Nominal Data

Nominal data is the name given to types of data that describes a group or category, the word Nominal relates to name.

This type of data has no specific ranking order to it. With examples being things such as Country names, People’s names or department names.

It can be words, numbers or any mixture of characters such as a vehicle registration

Ordinal data

Ordinal data is similar to nominal data in that is based on a name. But those names do have an order to them for ranking purposes.

Examples of Ordinal data could be Gold, Silver and Bronze or High, Medium, Low.

Typically these data types need to have an associated field by which to sort them

Quantitative Data

Quantitative data is used to collect items that have a measured value, such as Sales, Prices or times

Which charts and graphs to use for which types of data

Understanding which type of chart to use for the most efficient presentation of your data type and timescales

Space is a significant limiting factor in dashboard design. But not all space is created equal, the human eye is drawn to specific areas more than others

Selecting the best type of visual for each type of information

Bullet Graph

A bullet graph is a horizontal type of gauge, it is a great of showing progress against a specific target such as Sales v Budget

Bar Graph

A bar graph is good for comparatives, being space efficient and easy to see relative values

Stacked Bar Chart

Stacked Bar Charts are use to combine a headline view, with a high level breakdown of the relative composition of sub categories within a category

Combination Chart

Combination charts bring together two types of chart into a single chart. Combining line charts with column charts in this example

They are useful when you need to show values that have a different scale but want to see the trend of multiple variables at the same time in the same space

For example, Showing Sales values and Gross margin percentages over time

Sparklines

Sparklines are a very compact space efficient way to show an underlying trend. Typically shown alongside a value in a table to give the single value more context

The below example shows that the sales this year are on an upward trend

Box Plots

useful to present distribution of data around a median, with upper and lower values, e.g. defect rates

Tree Maps

Tree maps are a space efficient way of breaking down a hierarchy by values, to quickly visualise contributions to the whole

Pie Charts

Let’s start by identifying some potential problems with pie charts

Pie charts are not as space efficient as other chart options, requiring a lot of white space due to the circular shape

It can be very difficult to care the size of angles to each other so reading accurate values can be difficult, and this gets worse as the pie chart gets smaller

As more segments are added to a pie chart the need to have multiple colours or patterns can make them even more difficult to use

But, the real strength of pie charts is that they are widely understood and if used carefully they can be a user friendly option

By avoiding the weaknesses of pie charts, keeping the number of options to less than say five segments.

And using call out values to highlight percentages for easy comparison. Also using them in conjunction with other visual objects they can add a visual interest

Using pie charts as interactive filters on reports and dashboards can be a very useful tool

Tables

Tables for many people are more readily understood than a chart, it is often worth just presenting data in the form of a simple clear table

Maps

Maps are useful to measure relative geographic data which could be difficult to see any other way

The example below shows sales cannibalisation in Sheffield from a new store opening in nearby Rotherham

Make the best use of Space

Space is often a significant limiting factor, using this layout template can be a good way to try to keep a familiar look and feel

The image below highlights where you should consider adding the most important information for maximum impact, attention is drawn to the middle of the screen naturally

These data visualisation best practice tips are suitable for a wide range of business intelligence tools, the examples were created using Microsoft Power BI, but can equally be applied to Tableau, Google Data Studio or even Excel

This article was originally published in our business analytics blog
https://www.selectdistinct.co.uk/2022/12/27/data-visualisation-best-practice/

By Simon Harrison
Founder of Select Distinct Limited

6 Differences Between Data Exploration and Data Presentation

Zach Gemignani — Wed, 16 Mar 2022 18:55:00 GMT

There are big differences between data exploration versus data presentation. And you need to be aware of these differences as you're creating data stories and data presentations. Let’s start by defining our terms:

Data exploration means the deep-dive analysis of data in search of new insights.
Data presentation means the delivery of data insights to an audience in a form that makes clear the implications.

Your toolbox for data exploration tools is flush with technology solutions such as Tableau, PowerBI, Looker, and Qlik. "Visual analytics" tools give analysts a super-powered version of Excel for dicing data to facilitate the search for valuable insights. Flexibility and breadth of features is critical; the user needs to handle lots of data sources and doesn’t know in which direction she will go with the analysis.

Data presentation is a different class of problem with distinct use cases, goals, and audience needs. Think about the incredible data stories delivered by the The Upshot, Fivethirtyeight, and Bloomberg. These data journalists often demonstrate data presentation at its finest, complete with guided storytelling, compelling visuals, and thoughtful text descriptions. When compared to these examples, it becomes obvious that the best efforts by a data exploration tool cannot deliver high-quality data presentation.

You need a specialized solution if you really want to communicate data in ways that engage your audience. To understand the differences between data exploration and data presentation tools, let me offer six key ways that the activities are fundamentally different.

1. Audience — Who is the data for?

For data exploration, the primary audience is the data analyst herself. She is the person who is both manipulating the data and seeing the results. She needs to work with tight feedback cycles of defining hypotheses, analyzing data, and visualizing results.

For data presentation, the audience is a separate group of end-users, not the author of the analysis. These end-users are often non-analytical, they are on the front-lines of business decision-making, and may difficulty connecting the dots between an analysis and the implications for their job.

2. Message — What do you want to say?

Data exploration is about the journey to find a message in your data. The analyst is trying to put together the pieces of a puzzle.

Data presentation is about sharing the solved puzzle with people who can take action on the insights. Authors of data presentations need to guide an audience through the content with a purpose and point of view.

3. Explanation — What does the data mean?

For the analysts using data exploration tools, the meaning of their analysis can be self-evident. A 1% jump in your conversion metric may represent a big change that changes your marketing tactics. The important challenge for the analysts is to answer why is this happening.

Data presentations carry a heavier burden in explaining the results of analysis. When the audience isn’t as familiar with the data, the data presentation author needs to start with more basic descriptions and context. How do we measure the conversion metric? Is a 1% change a big deal or not? What is the business impact of this change?

4. Visualizations — How do I show the data?

The visualizations for data exploration need to be easy to create and may often show multiple dimensions to unearth complex patterns.

For data presentation, it is important that visualizations be simple and intuitive. The audience doesn’t have the patience to decipher the meaning of a chart. I used to love presenting data in treemaps but found that as a visualization it could seldom stand-alone without a two-minute tutorial to teach new users how to read the content.

5. Goal — What should I do about the insights?

The goal of data exploration is often to ask a better question. The process of finding better questions gets to new insights and a better understanding of how your business works.

Data presentations are about guiding decision-makers to make smarter choices. Much of the learning (through data exploration) should be done, leaving the equally difficult task of communicating the insights and the actions that should result.

In all these ways, data exploration and data presentation are different beasts. This is why we’ve chosen to focus on building the best possible data presentation tool, Juicebox.

6. Interactions — How are data insights created and shared?

Data exploration can be a lonely endeavor: Analysts work on their own to gather data, connect data across silos, and dig into the data to find insights. Data exploration is often a solitary activity that only connects with other people when insights are found and need to be shared. That is, when…

Data presentation is a collaborative, social activity. The value emerges when insights found in data are shared with people who understand the context of the business. The dialogue that emerges is the point, not a failure of the analysis.

Finding the Middle Ground: Data Storytelling

There is something between the extreme ends of data exploration and data presentation. We believe data storytelling lies in this intersection. Data stories aren’t entirely about “telling”, nor are they in the wilderness of “finding”. It is the opportunity to explain the data in a guided, narrative way where message meets exploration.

While there are tools for exploration (e.g. Tableau) and tools for presentation (e.g. PowerPoint), it is only recently that you’ve had the change to bring both together in one solution.

Zach Gemignani (zach.gemignani@juiceanalytics.com)

CEO, co-founder, author at Juice Analytics

www.juiceanalytics.com

Top 10 Mistakes in Requirements Elicitation

Trividh Patel, CBAP — Tue, 27 Apr 2021 05:47:00 GMT

Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified.

1. Not understanding underlying business need

Organization’s business environment keeps changing with respect to Customers, Marketplace, Technology and Marketing function. It is these changes in business environment that leads to identification of business needs at the strategic level in terms of problem or opportunity faced by the organization.

Defining business needs is the most important step in business analysis. Without understanding and defining underlying business needs, it would not be possible to identify all affected stakeholders and elicit appropriate requirements.

2. Not identifying all affected stakeholders

It is important to identify all the stakeholders affected by the given business need. If any stakeholder is identified late (or worst not at all!) may lead to incomplete set of requirements and could require a revision to requirements increasing project cost and time.

3. Treating elicitation as a phase

I have found many Business Analysts consider elicitation as a phase after planning (and before requirements analysis). But this is not true. If you think little more deeply, information gets elicited whenever we interact with stakeholders such as sponsor, domain subject matter experts (SMEs), implementation SMEs, users etc.

Elicitation is performed to understand the current state and elicit business requirements. Business requirements are used when eliciting stakeholder, solution and transition requirements. During requirements analysis, we may identify gaps which would require further elicitation. Information is also elicited from the stakeholders about solution performance after implementation of a new solution.

So elicitation is performed on an ongoing basis as long as business analysis work is performed.

4. Not asking probing questions to elicit requirements

Many novice Business Analysts assume stakeholders can proactively provide all the detailed information required for the business analysis work. Such a passive approach can be called requirement gathering but not an elicitation. Such an approach can only lead to identification of shallow requirements.

It is the job of the Business Analyst to extract or draw out the detailed requirements from the minds of the stakeholders. Business Analyst need to ask probing questions to elicit detailed requirements.

5. Not setting stakeholder’s expectations

In your career as a Business Analyst, at times you would find some stakeholder who would state their wants (whims and wishes!) as if they are their needs and expect them to be in the solution. You may find their expectations not only difficult but impossible. If you capture their wants as requirements it would be difficult later on to deliver to their expectations.

With your interpersonal and negotiation skills you need to communicate and set the right expectations.

6. Not using combination of complementary elicitation techniques

I have seen many Business Analysis teams often rely only on one technique such as interviews for elicitation. While interviews is the most effective elicitation technique but its effectiveness depends on the skills of the Business Analyst such as business domain knowledge and ability to ask probing questions.

So, apart from interviews, a Business Analyst should have knowledge of other commonly used fundamental requirements elicitation techniques such as Document Analysis, Observation and Prototyping. While a senior Business Analyst should have knowledge of advanced elicitation techniques such as Brainstorming, Focus Groups, Requirements Workshops and Surveys.

A Business Analyst should be able to understand the given situation and use combination of complementary elicitation techniques.

7. Not eliciting assumptions and constraints

Requirements are often stated (knowingly or unknowingly) based on certain assumptions which are believed to be true at that time. Requirements get impacted if those assumptions are later found to be false.

Constraints are limitations or restrictions (such as regulatory restrictions, budgetary restrictions, time restrictions etc) that restrict potential solutions to requirements. Identified potential solutions may change if there are any changes in the constraints.

If underlying assumptions and constraints are not captured for requirements, it would be difficult to assess impact on requirements if certain assumptions are later found to be false and/ or on potential solutions if constraints are changed.

8. No plan to elicit requirement iteratively

In order to elicit requirements, a Business Analyst contacts a stakeholder and requests their time. Many Business Analysts do not plan to elicit requirements iteratively and assume that stakeholders will provide all the information required for the business analysis work.

However, most of times, stakeholders are not aware why they are being contacted. After their initial meetings, stakeholder will have some idea what is expected out of him/ her. In the subsequent meetings, stakeholder is likely to give bit more detailed information. So, in order to elicit detailed information, Business Analyst needs to plan to elicit requirement iteratively.

9. Not confirming the elicited information

Work of elicitation is not over once Business Analyst is done talking to stakeholders. Business Analyst has to organize the elicited information and send it to the stakeholders for review. The purpose is to check if discussion has been properly documented and confirm the elicited information.

10. Not collaborating with stakeholders to have common understanding of requirements

When the elicited requirements are shared with stakeholders, there can be difference of opinions and conflicts between stakeholders. A Business Analyst has to collaborate, mediate and resolve conflict between stakeholders to reach a common understanding of requirements. Business Analyst should identify the stakeholder’s problems and help to identify solutions to satisfy those problems.

About Author - Trividh Patel, CBAP

Trividh Patel has about 20 years of experience in Business Analysis and Consulting in IT services industry.

Currently, he is working as Facilitator and Mentor - Business Analysis providing self-paced online courses in Business Analysis. Previously, he has worked for leading IT Services companies as Business Architect, Lead/ Sr. Business Analyst, and as IT Project Manager. He has executed several business analysis projects for reputed organizations from USA, UK, Europe, Middle East, Japan and India. He has good track record of leading team of Business Analysts to deliver business analysis projects.

Trividh Patel has done MBA in Systems and Bachelor of Engineering from University of Mumbai (India) and is Certified Business Analysis Professional (CBAP) by International Institute of Business Analysis (IIBA), Canada since March 2012. He is also Certified Six Sigma Black Belt.

For Consulting, Coaching or Guidance on IIBA Certification (or just to connect!), Trividh Patel can be reached on LinkedIn: http://www.linkedin.com/in/trividhpatel-cbap

The Case Against Process Mapping and Why You Should Do Process Discovery Instead

Simona from Minit — Mon, 06 Aug 2018 08:44:00 GMT

Process mapping vs. process discovery is akin to perceived reality vs. reality; the former rooted in subjectivity, the latter rooted in verifiable data. Elements of process mapping creep into process discovery, restricting an absolute dichotomy between the two. However, the critical differentiator between mapping and discovery lies in the distinction between fact and fiction. Process discovery is primarily concerned with concrete, verifiable data (event logs, digital footprints), while process mapping relies on subjective first-hand remembered events.

Let us first review the core definitions of process mapping and process discovery before moving to the case against process mapping in favor of process discovery.

Key Differences Between Process Mappingig and Process Discovery

Process mapping is the human-side of establishing an ‘as-is-process.’ It’s concerned with measuring and comparing a defined objective against an organization's larger vision to ensure process are aligned with a company’s core competencies, capabilities, and overarching values. While the end game aims for process improvement, a significant element of subjectivity and unintentional validation techniques are laced within manual process mapping. Perceived reality is flawed regardless of intentions.

Automated process discovery, on the other hand, is exclusively concerned with verifiable data logs, providing an accurate picture of how processes are performed, rather than the idealized model of how they should be performed, or how employees think they are performed. Additionally, process discovery takes the white space between information systems and seemingly unrelated events and builds bridges with data rather than assumptions. Anomalies and outliers are accurately weighted without being unfairly amplified or ignored

Process Mapping	Process Discovery
Manual	Automated
Subjective	Objective
Remembered events	Verifiable event logs
Human validation	Data-driven
Limited scalability	Full scalability
Process details must be known by employees	No employee knowledge of process details needed
Slow, drawn-out	Fast, continuous
Too much or too little detail	Exact reality
White space between IT systems and processes unknown	White space between IT systems and processes bridged
Outliers ignored	Outliers appropriately weighted

Process Discovery vs Process Mapping — Why Discovery is Best

The case for process discovery is strong, particularly when midsize and enterprise level companies are looking to initiate Business Process Improvements (BPI). From knowledge gaps bridged to socio-cultural subjectivity eliminated, here are the top reasons to choose process discovery over process mapping.

1. You don’t know what you don’t know (white space)

White space is the unseen area between various systems, departments, and functions at the edges of a process. One of the most significant challenges in manual process mapping is effectively extracting information from employees involved in a process. Piecing together “remembered activities” to create a process map will inevitably be riddled with knowledge gaps, employee validation, and human subjectivity. In other words, you don’t know what you don’t know, and “unseen” events will not be included in the map.

Process discovery captures all the nuances of a process, including statistical information, process exceptions, unusual transactions, deviations, potential process risks, bottlenecks, and variants. Process discovery bridges the gaps between the individual process steps across multiple ERP and IT systems. Automated process discovery delivers a detailed process map rich with data and flexible for interactive analysis.

2. Map unstructured data from process unknown to employees

Concerning white space and knowledge gaps, some processes, and steps in a process are entirely unknown to employees and, therefore, must rely on digital event logs to create a picture of a process. Consider a global supply chain operating on Just-In-Time manufacturing principles. This fast-moving, lean approach to production relies on multiple actions triggered by a single event. Building on verifiable, time-stamped data logs from hundreds to hundreds of thousands of tiny events is something humans simply cannot map. Process discovery systems, like Minit, take this unstructured data and automatically create a process model to enable in-depth analysis. Minit technology is able to take various data inputs from scratch and deliver pattern recognition. This enables companies to discover processes without prior process knowledge or specifying an existing model.

3. Eliminate socio-cultural behavior from analysis

Humans make decisions based on emotions. It’s a fact wired into our neurological pathways. This doesn’t mean we are illogical, far from it. It means we gather information, process this information from our lens of reality, and then use the frontal lobe of our brain to make a decision — the area responsible for emotional expression, problem-solving, memory, language, and judgment.

Without intent for sabotage, humans will deliver a subjective view of reality, as well as use unintentional validation techniques. It’s not lying; it’s how we communicate as humans. Automated process discovery reads between the lines of data logs, not words, eliminating the presence of socio-cultural behavior from a process analysis. Additionally, what manual process mapping may express as statistical noise, process discovery can appropriately highlight as inefficiencies in business processes.

4. Focus on accuracy and speed

Have you ever seen a whiteboard overloaded with sticky notes — diamonds, arrows, mini-sticky notes upon larger sticky notes? An array of orange, pink, blue and green activities? This is process mapping. Process mapping can, and should, be accompanied by technology like Microsoft Visio and purpose-built process mapping tools, but keep in mind that these tools help you take sticky notes off a white board and build sticky notes on a computer screen. Your big win here is that a humid day won’t wipe progress off the board. This approach is still relying on human inputs, not data inputs, bringing accuracy level to a low.

In terms of speed, calculate the total human hours needed for individual staff interviews, facilitated discovery workshops, analysis of existing documentation and direct work observation. Then compare this to process mining software that plugs in, transforms unstructured data into meaningful maps, and delivers a flexible, in-depth process analysis based on hard data. This is an essential part of understanding the real cost of going through a BPI transformation.

5. Unlimited scalability

Last but not least, a massive benefit of automated process discovery over manual process mapping is scalability. Once systems are connected and process mining software established, a process can be endlessly reanalyzed with little to no additional effort. As subtle changes in the process are made during the discovery period, technology will capture this immediately and include it in data mapping. Businesses need to optimize business processes continuously, and scalability is a big part of making this financially feasible.

See Process Discovery Technology in Action

Minit software analyzes concrete data from various systems to discover how business processes flow in reality. Our platform automatically recreates process maps from traces of user actions (electronic footprints) left within applications. It provides an accurate picture of how users — employees, suppliers, customers, etc. — are performing their duties or actions rather than the idealized model of what they are supposed to be doing.

We’d love to show you the power of Minit and how it can help deliver an effective BPI transformation at your organization. Get in touch with our team to learn more and request a trial of Minit.

Does Agile need Architecture to be successful?

EA Learning — Wed, 24 Jan 2018 03:21:00 GMT

On a recent Agile training course, the instructor opened the session by saying “Agile without a plan is just chaos!” I would like to propose that Agile without effective Architecture will eventually lead to chaos, particularly if organisations try to scale their Agile practices without some form of guiding framework.

The fundamental reason for this is that we all operate within constraints, which can be financial, regulatory, technical or customer driven. While Agile practices have traditionally been confined to software development there is a significant push by organisations, particularly at the Enterprise end of the market, to use Agile practices to manage traditional business functions. This new trend is euphemistically referred to as New Ways of Working. The benefits of leveraging Agile practices are numerous, with the fundamental benefit that organisations see Agile practices as a way to deliver improved outcomes for their customers and stakeholders, more efficiently and consistently.

There are numerous case studies citing the achievement of these benefits at a project level, but very few examples (to date) of successful Agile Transformations at Enterprise Scale. Proponents of Agile practices will point to the Spotify Model as proof that Agile Practices can be used to build a $13 billion Enterprise. Which is true, however, they didn’t do it without Architecture. They did it by leveraging Architecture and its practices as an enabler and not a governing framework. The way that Architecture worked within Spotify is quite different to how Architecture currently operates within Traditional Brick and Mortar Enterprises.

It is very hard to find a clear definition of the role of Architecture in Agile. The SAFe (Scaled Agile Framework) framework has done the most to identify the role of Architecture within an Agile environment. As with all things Agile the focus is to create consistent value and Architecture is no different. In SAFe they define two distinct elements of Architecture:

Emergent Design
Intentional Architecture

Emergent Design provides the technical basis for development and the incremental implementation of initiatives. It helps Designers and Architects to be responsive to changing customer/ stakeholder needs to ensure the initiative continually delivers value. At this level, SAFe practitioner’s see Architecture as a collaborative and interactive exercise through which the design element can emerge.

Intentional Architecture is a much more structured approach and more aligned to what many would identify as being traditional Architecture, that is a set of defined and planned Architectural initiatives which will both support and enhance the performance and usability of the initiative. In effect, Intentional Architecture is a clear recognition that we all need to operate within certain constraints such as choice of technology platform, financial budget, etc. If these constraints can be identified and incorporated into the initiative then the probability of the initiative being successful and delivering value is increased.

SAFe practitioners proport that by balancing Emergent Design and Intentionality Agile practices can be scaled to deliver Enterprise level solutions. In Safe, this combination is referred to the Architectural Runway which provides the technical foundation for creating business value. Which is in complete alignment with traditional views of Architecture.

The key to the success of this approach is the level of abstraction at which the balance of Emergent Design and Intentional Architecture occur. The fundamental behaviour that will determine this is collaboration. Architects need to be able to work productively with Agile Teams to provide fast and local support to manage Emergent Design while also helping Agile Teams to appreciate and navigate the constraints defined by the Intentional Architecture. One of the key attributes of Agile Practices is the fact that Agile Teams are encouraged to provide constant feedback to their stakeholders. As emergent designs develop Architects can use this information to adapt and develop the Intentional Architecture to ensure that the overall Architecture of the Enterprise is evolving with the organisation in the medium to long-term.

So does “Agile need Architecture to be Successful?” I would say the better question is “What type of Architecture does Agile need to be successful?” Agile requires Architecture that supports the way the Agile Practices deliver of outcomes (value). The type of Architecture that will do this will be a combination of a nimble reactive style of Architecture supported by a more traditional structured approach to Architecture. The challenge as with many things is to get the mix right!

Written by Scott Comte, General Manager of EA Learning.

To find out more about the EA Learning Business Architecture or Agile training courses please fill out the below form or click here to view our course range.

Are You Being a Design Illusionist?

Paul Crosby — Wed, 07 Sep 2016 14:31:00 GMT

As business analysts, we are often in the fray of designing. Whether it’s a user interface, report or data fed from one system to another; business analysts create interfaces with human beings and systems. Our design choices impact users and other systems in a very real way. This power can go unnoticed even in our own minds.

Have business analysts become illusionists and pickpockets? Both these skill sets require some of the same sleights of hand. The illusionist uses the blind spots and limits of human vision to fool us. If you haven’t had an opportunity to watch the show called “Brain Games” – give it a whirl. It does an excellent job of explaining how an illusionist can fool our sight and point of view. For the pickpocket, it’s the distraction of a conversation, a tap, or a bump to set your mind off in the opposite direction of where you should be focusing while a sleight of hand takes your wallet.

Are we as business analysts playing a role of illusionist and pickpocket when designing our interfaces? Let’s look at interfaces (such as screens and reports) in a broader sense. An interface in my mind is the presentation or “stage” an illusionist would use.

We all believe we have choices and freedom. Everyone in the western world most firmly believes they have great freedom of choice in being able to do whatever is desirable, affordable and of course legal. You can go just anywhere and do just about anything. But when confronted with a system, website or application with a menu of choices, we fail to see how we are hijacked.

We rarely ask the questions:

(1) What is NOT in the interface? Or why are these my only choices?

(2) What is the purpose or goal of this interface? What is it used for?

(3) Why are these options higher or lower on the interface? More visible or less visible as other choices?

(4) Are these choice empowering me or just distracting me from doing what I need to accomplish?

If you have every used a search engine like Google or an application like Yelp, you get a sense choices are made for you and only certain things are being presented for your attention. I have been told the nearest restaurant or gas station is several miles away – all the while standing right in front of one! I usually chalk it up to “well they must not have gotten into the database yet” but now I’m leaning more to thinking I’m being fooled by the choices I’m presented.

Back in the ancient days at the dawn of computerized civilization – something like 40 years ago for you youngsters – computers were called mainframes. Mammoth monsters that would manage large amounts of data, electricity and generate a lot of heat. They required a forklift to move and had to be water cooled.

In those ancient days of computer myths and data Gods, there was but the humble green screen. To get to all the crap stored in that giant mainframe required you to issue the magic commands. By locating the secret words in the sacred text called “Command Line Reference,” you could instruct the mainframe beast to perform feats of great wonder. In other words, there was a giant three-ring binder with all these commands listed in alphabetical order that you were required to memorize and type correctly. The mainframe didn’t tolerate spelling mistakes, and there was no such thing as auto correct. No Google-like “Is this what you mean?” ever appeared on the screen. Even the help key which was supposed to provide assistance rarely did. This was the world of complete freedom from “the menu”. All the commands were in the book and available and granted they didn’t cover everything you wanted to do, but they did cover a lot of stuff you needed to perform. Yes, you had to memorize a boat load of command line syntax because the mysterious book appeared and disappeared as it desired, but you never felt limited rather you just felt a need to search for the right command.

Enter the age of the personal computer. For simplicity, the command line went away. The mouse was born. There was nothing more entertaining than watching grown men in a room holding the mouse with both hands tightly but gently trying desperately to get that arrow moving in the right direction on the screen. “This mouse thing will never catch on” they grumbled. Suddenly the command line was gone, and menus or buttons presented to us. These were your options. Your only available commands. It didn’t take long before I missed my giant 3-ring binder of commands that gave me all the power.

Over time we became to believe that only the commands we could see were the ones of importance. We would become less and less frustrated at not seeing the things we needed. We are restrained by choices of actions presented. Our perception came to be that if it wasn't presented, it wasn't available.

So let’s take this into the modern smartphone age. The other night friends and I were out at a restaurant having a great conversation. The restaurant was closing because it wasn’t that busy and the owner wanted to call it a night. We asked each other the question “let’s continue this conversation – where should we go?”. We all pulled out our smartphones pulling up Google, Yelp, and the other thousand apps on our smartphones looking for a place that was open late. This searching went on for 15-minutes or so. Now I can be a bit impatient with technology and frankly don’t always find it of much help in situations like these. I quit my search letting the others wade their way through the digital data flowing around with smartphones. Then I looked up.

A beautiful park lay right before our eyes across the street, and we didn’t even see it. We believed our only options to find some place were those our smartphones provided. Did those applications tell us about the park? Not one. How about that food truck with the fabulous desserts? Nope. Not a single one. Our illusion of having choices was broken. Sure we got a lot of options, but it was all about the pictures of the menu or comments from other people that distracted us from answering the exact question “Where should we go to keep talking?”. The menu or interface design didn’t answer our actual question at all. It created the illusion of choice by presenting a small subset of options. All said and done the park was bug-free which is a miracle in Minnesota some evenings. Dessert and conversation continued for hours in the street lamp lit park.

As business analysts or designers, it is easy just to limit user choices to a few as possible to send them down a well-defined and perfectly groomed path. But does that answer their question? How many times have you wanted to say “Siri – lead the way to a great evening with my friends!”. The response from Siri is, “I’m sorry I don’t’ understand what you are asking”.

There are a thousand paths to getting or achieving something. No matter how hard you try to make it simple, it just winds up being even more complicated. Or worse the real thing you need is hidden somewhere because someone felt it wasn’t’ important enough to warrant a button. Some of the best interfaces look very simple on the front end and have a rich set of commands just slightly inside of the interface. As a business analyst and designer, we need to give our users or community a rich experience with our application. Are we the illusionist – forcing users down only one path? Our accounting system has several ways in which to generate an invoice. From a customer contact screen, main menu, sidebar and I’m sure more options remain hidden in the accounting interface. As I watched the finance, customer service, and sales people utilize the user interface with the simple task of generating an invoice, I noticed something important. Not everyone went about taking the same path.

Sales people always went to look at the customer inquiry screen first before generating an invoice. Individuals and their contact information were more important to them, and they would update it before moving on to creating an invoice. Customer service created invoices from the order screens as they were more focused on shipping products. Finance folks just clicked on the main menu option.

Know your users. They each have a story and a way of performing tasks that make sense to them. Think about their “persona” and what they need to accomplish. There is no single path to creating an invoice. Develop a list of capabilities and make sure they are not “hidden” from view. If it all doesn’t fit on a screen, find ways to expand the options for display when requested. Don’t fear including two buttons “Create Invoice” and “Add Invoice” which go to the same screen if it makes more sense to a broader audience of users. It is more about clarity for your users then consistency in terms.

What has a dinner in the park taught me? Smartphones are not as smart as we think they are. Everyone thinks they have choices, but don’t always see the most obvious choice because the choice is not presented in a way the user would understand. Question the choices presented and determine if they are the only choices.

Yes, I still miss my green screen terminal. CMD-1 key forever will mean “useless” help, and a blinking green bar on a black screen will always be a symbol of the endless possibilities to mistype ridiculously long string of text that doesn't make sense to anyone. And that huge 3-ring binder filled with commands-a-plenty works damn good propping the door open.

For more good stuff on business analysis and leadership, check out the blog at Bob the BA.

From Developer in India to Business Analyst Abroad

Adrian M. — Wed, 28 Jan 2015 12:19:00 GMT

Business Systems Analyst as a Career Option

If you are an IT professional in India, thinking of working abroad, you might want to consider a business/systems analyst position.

Why?

It’s a position in high demand with high earning potential and which can serve as a great foundation for moving up the corporate ladder into management or business operations.

In on of Money Magazine’s Best Jobs in America list, the Computer/IT Analyst career was ranked 7th, out of 50 best jobs, with a 10-year job growth of 36.10%.

In one of their “Best Careers” report, US News and World Report lists 25 professions that will continue to grow in demand. With the advent of outsourcing, it is not surprising that the software engineer or web developer professions are NOT on the list - however systems analyst is.

All industrialized nations are heavily outsourcing the programming of software to other parts of the globe such as Russia, India, China, Eastern Europe, and South America.

While there’s still demand for developers, of course, the information economy has created an ever increasing need for business analysts and systems analysts.

As a matter of fact, the very outsourcing of programming jobs has caused a spike in the demand for business systems analysts. The increase distance between the business stakeholder and the programmer has created an increasing need for higher quality and more precise analysis artifacts such as requirement documents and functional specifications.

In addition – in a more an more competitive economic landscape business organizations continue to strive to improve their business processes and reduce costs. Business analysts are at the center of most of these initiatives.

So are you ready to make the move?

Before you take the plunge, you should do a quick self assessment to determine if the business analyst role might be a good fit. You’re probably a good candidate if:

you don’t want to spend the rest of your career in front of a monitor debugging code,
you love to talk to people and socialize,
you not only love to talk to people but you are actually a good communicator,
you are good at organizing information in a structured and concise manner for others to consume,
you want to, and are able to, grasp the big picture,
you are fascinated by how companies actually make money, about the business systems and processes in place.

OK… so if you still think that business systems analysis is for you, then let’s take a quick look at what you need to begin a career as a business/systems analyst.

For starters, if you are a developer you already have a great advantage:

you think in a structured manner,
technology is not magic but something you actually understand,
you are most likely used to working in a variety of industries,
lack of detailed business knowledge causes you to ask very relevant “why” questions,
you know how to talk to the technical side, and
you probably have already been reviewing artifacts created by the business analysts.

So what’s next?

If I were forced to pick the top two skills or abilities that a BSA must have I will always pick strong communication skills and analytical (structured) thinking.

Communication Skills

The first thing you need to focus on is communication skills. No matter how good your communication skills are you can always learn more. This is a must have skill for the business systems analyst.

If you are assessing your abilities and trying to figure out which aspect of communication to work on next, here are some areas to consider (pick the one in which you are the weakest and run with it):

ability to verbally communicate your thoughts and ideas to others and make yourself understood,
ability to understand others and to ask relevant questions which cause the other party to give you the information you are looking for,
ability to write clearly and in a concise manner (when creating analysis artifacts - less is more)

Analytical/Structured Thinking Skills

The next thing is structured (logical) thinking… this is one of those aptitudes which, at some level, I almost want to categorize as “you either have it or you don’t.” However I haven’t yet found conclusive evidence to support my claims – not yet.

So for now, work on improving your analytical and problem solving skills as without them, you will fail as a business systems analyst or, at best, you will be a technical writer with a BA title.

If you are assessing your skills in this area you might want to consider focusing on the following:

techniques which help you organize your thoughts or the facts about a given problem,
methods of making a problem more manageable such as: divide and conquer, abstraction, problem solving patterns,
formal reasoning skills such as: propositional reasoning, identifying and controlling variables, suppositional reasoning, etc.

For more details check out Mind Tools, a good resources of ideas and techniques to improve your analytical and structured thinking skills.

Keep on Learning

While I would argue that a software developer/programmer with strong communication skills and great analytical/structured thinking can easily land a business/systems analyst job, there numerous other abilities and skills you should develop if you plan to make business analysis a long-term career.

Here are some things to think about:

Requirement Elicitation Methods – as a business analyst you will be eliciting requirements from the business stakeholders therefore it will serve you well to become familiar with various requirement gathering techniques such as: end-user interviews, job shadowing, questionnaires, etc.
Vertical domain knowledge – if you are interested in a given industry (ex: mortgage banking, pharmaceutical, etc.) or if you already have previous experience in a given industry you should consider beginning your business analyst career in that industry. Of course – learn as much as you can as the more you know about a given business domain the more effective you will be as an analyst.
Knowledge popular modeling techniques (activity diagram, sequence diagram, data flow diagram, workflow/process flow diagram, etc.)

Adrian

The Popcorn Way and the Business Analyst

Adrian M. — Wed, 03 Dec 2014 12:20:00 GMT

The problem: Do you know when you’re done?

Given a specific project with a reasonably defined charter and clear business goals you, the business analyst, set out to elicit and document the detailed business requirements.

So when do you stop?

Whether you lead a team of business analysts or you do the work yourself, you probably struggled trying to determine when you should be done gathering the requirements?

If you are a perfectionist, or know one, you’ll realize that it is possible to spend unlimited time trying to discover new requirements or to refine existing ones. However, in real life and real projects the customer cannot (and will not) spend unlimited amounts of money to build a system.

At some point you have to draw a line in the sand and say “We’re done… at least for now!” The crux of the matter is to determine when we’re done.

One of the most often quoted heuristics offered to answer this question is the 80/20 rule (or better yet the 20/80 rule). That is, spend the 20% of effort which uncovers 80 % of the requirements.

That’s easier said than done!

How do you know that 20% has gone by or that you have uncovered 80 % of the requirements?

To tell you the truth – I have no clue!

The Solution: The Popcorn Way

With the charter and goals of the project in mind, I estimate (or guesstimate) upfront how long I think the requirements gathering activities should last….

… and then I use The Popcorn Way.

I found the technique on the back of my microwavable popcorn bag.

I goes like this:

Microwave popcorn on high for 2.5 minutes (on 500 Watt microwaves) *
Listen for the distance between pops
When the distance between pops exceeds 2 seconds, turn off microwave.

* Note: the actual popping time may vary.

By now you’re probably thinking that I’m going crazy… and maybe I am… but that’s a topic for another time.

If you translate from Popcornish to English, it goes like this (see basic language lesson in appendix):

Elicit, document, and analyze requirements for {estimated duration} using {available resources}
Pay attention to the information that you’re getting and determine the duration between discovering new requirements or significant changes to existing requirements.
If distance between requirements is less than {the threshold for your situation and project}, then end the requirements gathering activities.

* Note: the actual total duration may vary due the type of project and the characteristics of the analysis team.

The basic thought is that during the requirements elicitation process it comes the time when you, the business analyst, realize that you’re finding less and less requirements even though you may be getting more and more information.

When you come to that realization – it’s time to stop – at least for now.

Putting in into Practice

Once you have mastered The Popcorn Way your gut will guide you.

You will be able to clearly spot the requirements silence.

You may be only part way during your estimated duration yet you’re not getting any new requirements or significant changes to existing requirements.

Stop! You’ve probably over-estimated.

Or, you may find yourself scrambling for the pen and paper (or typing 100 words per minute) trying to capture all the requirements flying at you… In this case, you’re definitely not yet done. Should you find yourself in this predicament after your estimated duration elapsed, you've most likely under-estimated the effort.

The Dangers of not following The Way (the Popcorn Way, that is)

I’ll keep this very simple:

If you stop too early you’ll have un-popped kernels => you've missed critical requirements and, from business analysis perspective, you failed.
If you wait too long you’ll burn the popcorn => you've wasted valuable time and probably made real requirements indistinguishable from the fluff. Again – this is not a desired outcome for a business analyst.

Do you use the popcorn method? Do you know when you’re done?

I would love to hear from you! Happy Popping!

The Appendix: Basic Popcornish Lesson

to Microwave (v.) = to elicit, document, and analyze
popcorn (n.) = requirements
2.5 minutes (n.) = the up-front estimate or guesstimate
microwave (n.) = business analyst or business analysis team
500 watts (n.) = an attribute which measures the caliber of your team
distance between pops (n.) = time elapsed between receiving a new requirement or making a significant change to an existing requirement
2 seconds (n.) = the longest time your situation (you can replace with organization, team, management, etc.) will allow you or your team to stay idle while waiting for a new requirement or a significant change to an existing requirement

Your turn: How do you know when you're done or when you should be done?

Adrian

Come to me with problems, not solutions

Pjbussol — Fri, 28 Mar 2014 20:06:00 GMT

“Bring me solutions, not problems”. How often have we heard those words uttered by management? In the main it’s a sensible ask however, for a Business Analyst, quite the opposite is true. Our job is to define business problems when often we are presented with solutions.

“We need a new reporting tool because the MI we receive isn’t always correct”.

We could initiate a project on this basis; gather detailed requirements, develop a new reporting tool and roll it out across the organisation but would this address the issue and if it did, would it really be the most effective way to do so?

Could it be that there is a problem with the data entry or with the way the MI is being interpreted?

The above problem statement is merely a symptom of a problem and does a poor job at describing what the real problem is.

Would a Doctor simply prescribe pain killers to a patient who complains about headaches or would he probe further, try to identify the reason for the headaches and offer treatment accordingly? So too must the Business Analyst probe deeper and recommend appropriate options.

The above illustrates why we cannot always rely on stakeholders to provide an accurate problem definition alone. There are other reasons too. For example, different stakeholders will have different (and sometimes conflicting) perspectives on the problem and for that reason, it is essential that the right people are engaged and the right information is elicited.

CFO - “We need a new reporting tool because the MI we receive isn’t always correct”

MI & Reporting Manager - “I need more resource because the demand for MI exceeds our current capacity”

Senior MI Analyst (Team Lead) - “There is too much re-work” “Team morale is very low”

MI Analyst - “The reporting suite is to complex. The MI that I provide is always correct but I’m often asked to redo work with slightly different parameters”

Night Watchman - “I’ve no idea. All I know is that boy seems to work awfully late!”

So maybe you might not interview the Night Watchman – but useful information does often come from surprising places!

In order to develop a true problem definition we must explore and challenge all of the problem statements that we have captured. In reality, there will be many and we must analyse each in turn to develop a short list of problem candidates.

There are many ways to explore the problem statements some common techniques are:

- 5 Whys

- Root Cause Analysis

- CATWOE

An explanation and templates for these techniques are readily available online.

Once we have our problem candidates, we should assess each of them in turn to determine whether they are in scope, relevant, a true problem or feasible. This should then lead to a clearly defined problem definition or in some instances a number of defined problems. When a number of valid problems are identified, the Project Team and Sponsor should decide which one to address.

So, the final step will be to get the problem owner to confirm and accept the problem definition but remember, never, ever go to management with a problem! Not without an appropriate solution anyway!

- See more at: http://www.peterjefferies.co.uk

Negotiation skills – are they really for Business Analysts?

David Wright — Fri, 13 Sep 2013 01:10:00 GMT

I keep seeing in BA skill descriptions or in specific articles that ‘negotiation skills’ are a necessity for Business Analysts. I just don’t see it myself. Negotiation is a difficult activity for many people, and I see this trend as an attempt to offload negotiation to other people… like Business Analysts.

Why do I feel this way? As an activity, ‘negotiation’ is when people with differing needs but overlaps in other areas (like sharing resources and money) need to reach an agreement that helps them in some way while giving up something in order get that agreement. In business, and especially IT, the need to reach such agreements occurs all the time. It often looks like this: a business unit has objectives to reach and a certain budget, and they need enhanced/new systems to reach the objectives. IT has the resources and tools to do the work. Both have useful but always limited assets.

In this situation, Business Analysts have no assets to negotiate with, what BAs bring to the table are analysis skills. It is the business and IT that need to negotiate an agreement about money to be spent on IT activities, including what the business gets for their money, and when they get it by. Business Analysts bring enough detail and clarity to these points so that both parties are happy; the business is able to define what they need, and IT is able to say what it will take and how long it will take.

The nature of limited resources and increasing time-to market pressures will almost always result in the business wanting more they can afford and/or want it sooner than it can be delivered. This is usually where ‘negotiation’ is said to occur by Business Analysts, but it only happens if one of the parties offloads their participation to the BA, who is told what to offer but has no real authority to bargain.

The better situation is where both sides remain engaged and the BA uses techniques like prioritization to help reach an agreement on acceptable deliverable for a feasible price and time. All through this, the BA is a ‘facilitator’, not a ‘negotiator’. Smoothing the way to agreement makes life is easier for the real negotiators; if we BAs do our jobs well enough, the involved parties will never even know or feel that they were negotiating!

How to identify a good (and bad) Business Analyst?

Kunal Jain — Sat, 13 Jul 2013 16:54:00 GMT

Over last 6 years, I have come across more than hundreds of analysts and have conducted almost equal number of interviews. Over this time, I have developed a knack of differentiating best analysts from good and good analysts from bad. If you face this challenge regularly, this post might help you.

So how do you differentiate between good and bad analysts?

Thankfully, it’s not that difficult. I have put a framework around how to judge an analyst. You can use the same to make your life simpler. This framework has it’s genesis in hiring guidelines at Capital One. I have modified it to include additional parameters which I use during interviews.

Structured thinking

This is the most important attribute that distinguishes a good analyst from bad. This attribute is not only required to be a successful analyst, it becomes absolutely critical for a person managing Business Analysts.

So what is Structured thinking?

Structured thinking is a process of putting a framework to an unstructured problem. Having a structure not only helps an analyst understand the problem at a macro level, it also helps by identifying areas which require deeper understanding.

How do I test for structured thinking?

Typically I test this by throwing a open business problem at an analyst and then observing closely how he / she is solving it.

An example is asking a question like: “You have been appointed as CEO of a loss making restaurant at Delhi / London Airport and you are expected to join the company in a week. What would you want to do as a CEO of the company as soon as you join them?”

If the person lays out a nice structure about where the problems could be, he has already ticked one box. If he starts giving you answers out of his hat (e.g. I would be looking at what marketing are we doing?), you should consider it as a red flag. He will not be able to sail through the world of Analytics.

Business understanding and problem solving

There is a reason why Business Analysts are called so and not just Analysts. Until a person understands what he is trying to solve and the business owners are confident that he can solve problems in meaningful manner, he is a dead analyst.

So, how do you test for business understanding?

For an experienced analyst, I typically start judging this by asking about business context for the projects he might have worked on. If he can explain that clearly, it’s a good start. If he can’t, you can almost make your hiring decision here. Next, you can look at the answers a person gives in response to question asked for judging structured thinking. If he gives answers based on numbers only, you need to probe him further. He needs to put a business thinking hat and provide some out of box suggestions.

Attention to details

If a person is not detail oriented, he can never be a good analyst. Every analyst should have the ability to understand business at high level, but he should be able to get down to nuts and bolts of all the levers you might have.

So how do you judge for attention to details?

Start by looking at the CV of a person, has he spent time choosing words carefully? Has he mentioned impact of the projects he might have worked on?

For an experienced analyst, probe on the projects he might have worked on before. Did he consider all the aspects and possibilities? How much time does take to explain his previous projects?

Another way to judge it is by asking the candidate to a guess estimate, something like “Estimate the number of smartphones used in India” and looking at how the candidate answers them. How many factors does he consider to come up with answers? How many segments does he consider to arrive at sizing? These aspects should give you a good read on how detail oriented a person is.

Ability to triangulate numbers & do back of the envelope calculations

While the first three characteristics help you identify a better than average analyst, this characteristic and the next differentiates best of analysts from good analyst. This is an activity I love to do and something I know every good analyst loves. This is the ability to set up equations on page and then do back of the envelope calculations to answer 80% of questions without touching any excel / calculator or laptop. It is also the ability to arrive at a number through various sources and then validating them.

How to judge ability to triangulate numbers and do back of the envelope calculations?

Guess estimate comes to your rescue here. Just ask the candidate to perform the guess estimate on a paper and then ask him to validate the number through an alternate approach.

Communication skills – Ability to tell stories based on numbers

Any analyst is only as good as he can communicate. If a person can not take the complex world of numbers and create a meaningful story out of it, he will always be looked upon as a nerd. He can be a good analyst, but not the best one. Ability to create a story and present it almost has an equal, if not higher influence on your customers and hence increases the chances of success of any analytics project.

How do you judge communication skills?

You can get a sense on this through the entire interview. If this is very critical to the role you are evaluating for, you can provide datasets in excel and ask the person to present some open ended questions

Hopefully, this framework will help you for any analyst hiring in future. In case you have some suggestions, do let me know.

Kunal Jain

Blogger, www.analyticsvidhya.com

kunal.jain@analyticsvidhya.com

How to convince stakeholders of BA value for the first time?

Lee Grinberg, CBAP, PMP — Fri, 21 Jun 2013 13:46:00 GMT

In my previous posts I outlined how I was able to succeed being the first and only BA at a company and the importance of establishing trust between you and the stakeholders.

So you're the first BA at a company. All are looking at you and thinking what can this person do for me?

Good question. What can you do for them?

Show them how your contribution will make their life easier!

I'll tell you how I handled this challenge. I was brought in to write functional specs based on business requirements. The business requirements were good but not complete. The IT folks were afraid that key use cases were missing.

I took the following steps:

Created a context diagram (first one in the company) to show them what scenarios may be missing
Created use cases from the business requirements
Reviewed both with the SMEs. This uncovered many gaps not covered by business requirements

Once gaps were uncovered, the people writing the business requirments were relieved to know the gaps were identified early in the process and not in a later (embarassing) stage. I made their life easier and this was appreciated.

The next steps were around design:

Wrote a detailed functional spec outlining database and functional changes
Clearly wrote out testing scenarios

So what, you may be thinking. After all, this is what BAs do. True, but remember, I was the first and only one in the company so no one was convinced of the value of a BA.

The result of design was that developers were relieved to know they didn't have to have lengthy conversations with the end users about functionality.

The key concept again is to make their life easier!

Once trust is established, however, you must prove that you can benefit the stakeholders.

Feedback cycles, meet deadlines. NOT good bedfellows

theBetterBA — Sat, 08 Dec 2012 20:12:00 GMT

Its quite a feat of strength to pretend you don’t have any weaknesses. I don’t pretend to be that strong.

Its quite a bit easier for me to look for faults, gaps, misses, short comings, imperfections and details that spell out why something is not right.

Its a blessing and a curse.

Looking at my deliverables in this light is second nature to me. Seek out opinions. Get critique. Make your work better. Constantly strive to push yourself.

But how often is that process of seeking critique under as much scrutiny as our work? Is it not as important? The means by which we seek out advice, and how we incorporate it is a corner stone of our work ethic.

It is much further reaching than our current project or task. It becomes part of the mechanism by which we operate. Its how we interact. Its how we present solutions and spread a sense of ownership. Its how we build teams and get stakeholders working together.

Collecting feedback, analyzing risk, determining scope are all facets of our role that we bake it into our projects. Its what makes us Business Analysts, Project Managers and good at our jobs. Its second nature.

(Image referenced from Qualtrics.com)

Until recently, what I have failed to realize about myself is where my “Assumptions & Constraints” are not being considered when I write my own “System Requirements”. Where can I improve? What about me is a risk to the business? How can we neutralize that risk?

For example, a portion of me that is very nearly atrophied since college is the ability and respect needed to accommodate deadlines. What’s the solution? If we can take a look at ourselves, at our weak areas through the lense of a requirements document, we may have immediately obtained that objective view that is necessarily to address a business problem.

Looking through the Requirement Document Lenses at Ourselves:

Analyze ourselves and the situation to define the problem (the Root Cause); ask others for thier throughts too
Identify what success is going to look like (our Business Requirements) when we’re done
Outline how are we going to deliver that success story (our Functional Requirements)
Think through all the places our impact has reaches (use cases)
Add some limits and restrictions we’re likely to encounter when working through our problem (assumptions and constraints).

We could take this to a whole new level, and write out sample requirements – which I may yet do! – but it is enough to employ this objective tool that we use on our projects as a way to address our own business strategies.

How are we going to get where we need to be? What do we need to do to get there? What does success look like?

Going to be asking myself these questions for some time to come.

In the mean while, one of my own business concerns is the need to address my ability to meet deadlines. Its not as easy as it is to type it on your resume. It actually means something.

What is a deadline, really? Well, according to the Wiktionary:

deadline (plural deadlines)

A date on or before which something must be completed.

I must make this deadline or my boss will kill me!
(archaic) A guideline marked on a plate for a printing press.
(archaic) A line which doesn’t move.
(archaic) A boundary around a prison

The connotation around number 4 could prove to be a bit extreme etymologically speaking, but what does this definition tell us? Probably nothing we didn’t already know. Its a date. A date by when something is due by. Not hard, right? I pay by bills by a date, I get my car’s oil changed by a date, I go to the dentist by a date. Easy peasy.

Not so much. A deadline means so much more than how its defined. As a matter of fact, weare often the ones defining the deadlines. We define the deliverables. We define the dates. Its so much more than doing something by a date, its defining what needs done by when.

Need to ask ourselves about our deadline, to help define it for our circumstance:

What are some risk mitigation strategies for your deadlines?
Where does your deadline get communicated?
How to do you state your deadline?
How soft or hard is this deadline?
What is going to impact this deadline?
Is this deadline clear, or clear as mud?
What is expected at the end of the deadline?
How do you estimate your deadline?
When should you ask advice before giving your deadline?
When should escalate a concern about your deadline?

Communicating and escalating risks earlier is also a key component to meeting and estimating deadlines consistently.

Here is what NOT to do:

Provide a deadline in this format “I’ll have that to you sometime on Friday”;
Jump on the first distracting or more fun project thrown in front of you – any chance to do something else
Let scope creep out and destroy your project plan as that hard earned feedback rolls in;
Wait to escalate a problem until after you’ve run out of time

Here is what you could do:

Provide specific dates, and times
Communicate multiple dates – be as transparent as you can be; what is the ideal/ best case scenario? What is more likely to be delivery date? What is the worst case scenario? Express your concerns immediately.
Communicate as soon as you are aware of what will impact that will have on your plan to meet your estimated deadline
If you are unsure, ask for time to think about it, and get back with your estimate later
Include a confidence rating on how confident you are that deadline is likely to be met
Don’t be easily distracted from your original plan – escalate the question to someone who can see the bigger picture, your manager or director
“Communicating early” does not mean to wait to communicate when the deadline is slipping, it means to communicate as soon as you’ve identified something that may cause it to slip.
When the impact of an unplanned activity has equal priority, escalate the decision immediately. Don’t think you can make that call with out being the tiniest bit subjective – when we’re that close the project, we’re often too close to make the best call for the company.

It takes time to systematically approach a problem until its second nature. Thinking of deadlines, feedback and scope creep in terms of requirements feels more systematic, more error-proof, and more organized.

Good luck, and happy self-analyzing!

The Role of the Requirements Analyst in Driving Specialized Development Teams to Success

Seilevel — Sun, 27 Feb 2011 15:11:00 GMT

I am working on a project where Development teams are divided into specialized areas called Centers of Competence. For example, one team works on Customer data, another team on Product data and validation, another works with the Shopping Cart, another with Checkout and so on. Requirements are gathered within each of these Centers of Competence and handed off to Development for implementation.

The above approach works very well for modular functionality that is specific to a Center of Competence. For example, features specific to Customer Create are usually handled within the Customer Center of Competence and do not impact any of the other teams. But when Customer data flows from one team to another to be used further downstream for pricing, taxation, product segmentation and so on, the modular structure of requirements definition and development breaks down.

This is where the Requirements Analyst plays a crucial role in ensuring that proper functionality is developed. The key techniques we have used to ensure requirements flow across the modular functionality boundaries are as below.

1. Identify all development teams impacted by a requirement or feature request. For example, some specific Customer data may need to be captured to ensure proper pricing and taxation. These requirements will likely originate within those specific Centers of Competence, but will be developed by a different team. So, the analyst creating the requirements will clearly identify the impacted teams other than just his or her own Center of Competence.
2. Communicate clearly to impacted development teams the functionality they need to develop to support requirements in a specific Center of Competence.
3. Get estimates of time to develop, test and deploy from the other impacted teams. This is tracked as a separate task that must be completed prior to requirements being signed off for a release.
4. Conduct cross functional development and requirements meetings so that all impacted teams clearly understand the functionality that needs to be developed.
5. Define clearly the interfaces through which data and messages flow from one sub-system to another. Document any specific data requirements necessitated to support these interfaces.
6. Ensure that the test teams understand the implications for both unit testing and feature testing. There are typically two test teams to deal with. One test team works with a Center of Competence and the other is the global team that deals with the entire application.

All of the above tasks are managed, facilitated and executed by the Requirements Analyst. A good grasp of the overall application, a thorough understanding of data flow, an excellent working relationship with different teams and top notch facilitation skills are keys to success.
Good Requirements professionals managing both their individual areas and coordinating across boundaries are key to the success of the Center of Competence method of dividing and managing Development teams.

BA Careers - Is industry experience more important than Analytical skill?

HSantanam — Mon, 06 Dec 2010 19:32:00 GMT

Business Analysts often delve into business requirements, gathering, understanding and documenting business processes and functions. An analytical mind and detailed information gathering are considered to be essential; one wonders though, if industry experience is a must for good business analysis skills. After all, if you knew well the ins and outs of the industry you were in, that’s good, right? The answer is probably, but not always. Why is that?

Business analysts, like developers and solution architects, are trained to think logically and focus on specific issues at hand. Once in a while, though, they need to step back, and like a painter evaluating and assessing his painting-in-progress, assess their progress on the task at hand and be prepared to explain it to a wider audience in plain talk. That, in my opinion, is an essential skill of the modern analyst.

First, industry experience means less time is wasted knowing the industry environment – the general models the business follows, what regulatory and competitive arena it is part of and some common terminology. Secondly, business process flows are easier to understand, say, if one was documenting business process flows for a financial transaction, if that person had already worked in a financial services firm in a financial transaction environment (e.g., Front office, where the deals were made, or the middle office, where financial and regulatory processes were checked or filtered, and the back office, where the transactions were processed and settled – and where exceptions were followed up for closure).

That of course, brings up an interesting question – if a business analyst goes into an unfamiliar environment, how much time should be spent learning the business environment? Wouldn’t that leave less time for focusing on the essentials of requirements, elicitations and documentation? And how valuable would all that be, anyway? After all, time is money – and with workloads being what they these days, such knowledge, while good for a progressive and open mind, would be quite expensive indeed, wouldn’t it?

The answer is that depending on the timeframe, it would be beneficial to get the most important work done first, which would mean skipping the overview on the business. In a limited time frame, a “bullet-point” information dissemination method (summary) might work. Asking questions in the right environment is healthy, but learning important concepts on one’s own time is a better idea. After all, stakeholders have limited time available even for requirements – they might not have the patience for an extended basics class. On the other hand, workflows and the reasoning behind them should be questioned to extract the maximum value for optimization and better business.

What about the times when it might be beneficial to hire a business analyst who is sharp and curious, but not industry-knowledgeable? When the existing patterns are so constricted and “inside the box” that a fresh perspective is needed, hiring analysts without a lot of presumptions and insider’s knowledge is actually a good idea.

I worked in a firm once where I was asked to interview, evaluate and recommend IT candidates (mostly developers, some analysts). At the end of the face-to-face interview, I would ask the candidate to solve a problem on pen and paper. The rules were clear – no writing code, simply writing out the solutions – a diagram was acceptable as long as it wasn’t too complex. Additionally, the answer had to be limited to 1 page and be completed in about 30 minutes. I was amazed at how the smartest candidates failed this written “test” – it was actually quite simple, for it did not require deep industry knowledge and did not put the candidate on the spot by testing coding knowledge. I simply wanted to know how the candidate thought about solving problems and whether he/she was able to put it on paper. I often got several pages of answers, written code and requests for extending the time available, though all the requirements for the written test were explained before hand. Needless to say, these candidates were not hired.

Learned Processes

Seilevel — Tue, 26 Oct 2010 18:59:00 GMT

I know you are going to call me crazy, but I just have to let everyone know. Machines are controlling us. Don’t say I didn’t warn you. You don’t believe me? Okay, I’ll explain.

People come and go in organizations. Systems tend to stay much longer. Simple enough right? Here is the kicker. When that system was implemented, it was implemented to solve a problem. But it did not have all the capabilities required to solve all the problems the business had. So in order to fix the big problem, lots of little problems sprung up.

They weren’t an issue of course because the business had workarounds, usually manual ones. No biggie right? Well, maybe.

Let us say it is five years later and the original people who worked with the system are gone. The replacements were only trained on how to follow the process and not why the processes should be followed. There is the start; the machine has people doing its bidding.

Then a few years later it is decided that some systems should be replaced. So when all of the requirements analysts come in to do their thing, they document the process as is from the users and SMEs. This then gets propagated to the new systems. And thus, the old system lives on through the new system. The old bugs are now required functionality.

We must stop them! When working with old systems and processes don’t just ask what the current state of affairs is. Be sure to ask why it is done the way it is. This was happening on one of my previous projects. The inabilities of the old system were being written into requirements for the new system. Unnecessary needs for manual selections and processes were being maintained.

The project was so large and unruly that other requirements analysts would simply write down the current process and confirm it is how things work. This practice caused very complicated user interactions during the sales process and contract creation. After the fact, people realized that they should have automated more and asked the user questions about what to do less.

Because the software being implemented did not come with all this added functionality, it ended up costing the company much more money to reevaluate what was really needed, what could be covered by alternative existing features, and what would just go unimplemented.

By JHEEP

Want other software requirements posts? http://requirements.seilevel.com/blog/

Being New 101

Seilevel — Thu, 26 Aug 2010 19:04:00 GMT

Being a relatively new Requirements Analyst/ Business Analyst ( BA) and being new to the industry, I have been blessed with the opportunity to have mentors. Receiving direction from more experienced BA’s has definitely helped me find areas that I can improve on, while at the same time, finding my strengths and improving those too.

Yet there still are challenges that I face while trying to learn as much as possible. For instance, Senior Business Analysts, who are my mentors, will most likely be at client engagements for the majority of their time and it can sometimes be very difficult to find time to teach. Through my experience so far, I have learned a couple of tips that can help those aspiring and budding BA’s out there:

1. Always be on time
This cannot be reiterated enough. I will admit that I have had a slip up myself, but it is crucially important that a junior Business Analyst always be on time.

2. Ask informed questions
Never be afraid of sounding stupid. My mentors would rather me ask a “stupid question” that helps me understand the business problem than floundering about and end up making a mistake farther down the line.

3. Do not assume
Assumptions are bad. Always ask yourself what assumptions you are making when you are creating deliverables for the client. You may come up with some good questions or issues that your Senior Business Analyst didn’t catch before!

4. Use Spell Check
Spell check is your best friend when creating deliverables for clients. Not only does misspelled words make you look less credible, but it can make your organization look less professional too.

5. Take Ownership
Take ownership of the tasks that you are given. Don’t just wait to be fed information and small little projects. Instead, think of yourself being the sole proprietor of the task and think to yourself, “What can I do to make this successful?”.

6. Understanding Communication
Understanding what you are being asked to do is crucial. If you have a small amount of doubt in your mind, that is your cue to ask your Senior Business Analyst for clarification. The last thing you want to do is make the wrong assumptions and create something that the Senior Business Analyst didn’t ask for.

I hope that these little tips will help some of you aspiring and budding Business Analysts out there. I will be sure to add some more simple smart tips in my later blog posts!

http://requirements.seilevel.com/blog/

Lessons for a Good Hair Cut

Seilevel — Sun, 22 Aug 2010 23:22:00 GMT

Last year, I wrote about my Lessons from a Bad Haircut. I’m please to say I finally have a lesson from a good haircut.

How did I finally get a good haircut?

It was what the stylist did after I explained what I wanted. She drew a quick sketch. It took about 15 seconds. And, with that sketch, I was able to say “No, that’s not what I want.” 60 seconds more of discussing what I wanted while pointing at the sketch, and she’d refined the sketch until both of us were confident that we were talking about the same thing. The sketch was very crude and would never be confused with a work of art. But, that wasn’t the purpose. The purpose was to convey an idea. And it did. And, I got a good haircut.

So, what does this have to do with requirements?

Most people relate to pictures much more easily than to words. “Pictures” are all of the diagrams included in the RML®, such as process flows, wire frames, BDDs, etc.

One of the major things to remember about creating these diagrams is that they don’t have to be perfect to be useful. They simply have to be sufficient to convey the idea. And, once a model of the idea is out there, the discussion becomes very productive. If you can project the diagram or sketch it on a white board, people will point at it and discuss—what’s right? How do we make fix what isn’t? At the end the discussion, with an updated diagram, you’re ready to move forward with all parties confident they are headed down the same path.

When working with a client who wants me to skip the model and go straight to the words, I’ve found they react well to the statement “If we’re not in agreement about the model, we won’t get the words right.” They get it: it’s a matter of being more efficient and synching up our understanding as rapidly as possible, rather than wasting time on misunderstanding.

If I revert to my hair style of ten years ago–all one length and all I need is a trim–I can skip the sketch or picture. Otherwise, a picture or sketch will be a prerequisite to any haircut I get. I similarly recommend that requirements models be a prerequisite to any requirements you write.

Want to read other blogs? Check us out here.

What do you do when the client isn’t focused on the business outcome?

Seilevel — Tue, 17 Aug 2010 18:56:00 GMT

One of the values that we bring is that we can help our clients to decide what scope to cut by providing them with a framework that links quantifiable business objectives to specific features. We create an objective chain to do this and it helps to spotlight features that don’t feed into the core business purpose. Typically our stakeholders are able to cut a minimum of 10% of features and as much as 90% while achieving their objectives.

What we are finding though is that it is sometimes a challenge because the features that are good for the company are not necessarily good at making the lives of the people using the software easier or better.

We have recently run into a case (I’m changing the dollar values and the features for confidentiality reasons) where the business side of our client had identified $50 million in potential savings each year in an area of the business related to giving discounts. The issue was that the discounts were being calculated manually and there was the serious possibility that customers were claiming millions in discounts twice. The discounting system and rules are very complex with overlapping effectivity dates, products, regions and discount rules.

The business was confident in the $50 million number based on industry studies that showed that typical companies were giving away 5% more than they needed to in improperly calculated discounts. However, no one could identify specific types of problems that might be leading to double payment. We did a little research and analysis and decided that the biggest risk area was multiple overlapping discounts and so made that the focus.

There were several issues that came up. The most critical was that the users of the system and the business team while acknowledging the problem with overlapping discount agreements, were basing their decisions on the efficiency of the team. The calculating team is an offshore team with 8 people focused on this portion of the process. The company had done a study to show that full automation could reduce headcount from 8 to 2 people.

However our view was that the savings associatied with reducing headcount from 8 to 2 people was so minimal that it wasn’t worth the effort in the beginning when we were faced with such a large amount in overpayments. Instead we felt that focusing on the features that would automate detection of overlapping agreements were absolutely critical. Deploying those features as quickly as possible was paramount because of the massive revenue leak associated with the problem. Leaving a majority of the process manual would actually be ok if the system had the ability to determine when multiple discounts were being applied to the same purchase and thus eliminate the lost dollars.

It turns out that the business simply didn’t want to fund the project unless their work was decreased, even though in the overall scheme the cost savings was minimal. In the end they approved funding for a first phase that has full automation but does not actually focus on detection of the business case driving error conditions. The detection of the error conditions will come in later phases, so ultimately they will get the business value.

We see this often where at the level of individual features, the subject matter experts have mandatory features that will make their life easier but don’t necessarily contribute to the business case for the project. These features create a death by a thousand cuts situation. Our methodology can identify the “unnecessary” features, but ultimately it is up to the client to decide if the business case is really the highest priority.

Want to see other blog posts? Check us out here: http://requirements.seilevel.com/blog/

BA World Sydney - A review

Craig Brown — Tue, 27 Jul 2010 00:31:00 GMT

I went to the Business Analyst World Conference in Melbourne on the 19th and 20th of July. Like last year it was a great event. On day 1 I spent the whole day in one room (introducing speakers.) and got to listen to three very different stories.

Matthew Coppola from Perth training outfit Paramount Training gave a talk on Understanding Strategic Planning.

It’s always useful advice to go back to basics: Where do you want to be? Do you understand your capability? Mathew’s talk gave a simple framework to drill into these two questions. (See a transcripts of the whole talk here.)

Something that struck me while listening to his talk is how odd the world is. So many of us profess to know this stuff, but when you get out into the pressure of deadlines and complicated personal relationships – how many of us stick to the agenda and define the problem sufficiently before getting into implementation mode.

The second talk I saw was by John MacLeod of IBM’s Rational team on Steps to Better Requirements Management. This was the basics of requirements management: Start with a technology neutral business requirement statement, evolve it into a solution constrained by a particular IT or system scope and finally resolve it into specific statements of functionality. And trace things from front to back to keep up with what is getting done and what isn’t.

The third talk was a case study of a project delivered in NSW police by Peter Stanford of Artefaction called Architecting change – from Here to Eternity, or Agile and Now. This talk centred around the problems of getting consensus on big decisions in large, complex and diffuse organizations. The guts of the answer seemed to be making the decisions frequent and small, and using prototypes wherever possible.

On Day 2 I filled in for Paul Culmsee who was unable to attend – and did an ‘intimate’ Q&A session for two tables of people who wanted to ask questions about implementing agile practices. Matt Hodgson and Peter Stanford also sat in answering questions. It was fun and the people there seemed to like the more interactive nature of a conversation over yet another lecture.

The rest of the session was really interesting with lots of good content and speakers. I was happy I went and recommend anyone in Australia (or NZ) to pop along to the Sydney event on the 17th and 18th of August.

(Also posted at www.BetterProjects.net)

Work Harder, Not Smarter

Seilevel — Thu, 22 Jul 2010 16:13:00 GMT

I am all for great tools and processes that increase efficiency of work, facilitate better accuracy, allow for repeatable results, so on and so forth. But sometimes they simply do not fit. Yes, I just said better is not always good. Why? Spending time trying to improve tools or processes on short turnaround projects or tasks is usually detrimental to the goals at hand.

I have known several individuals who focus more on the tool than the deliverable. In one of those instances they were almost obsessed with the tool, an excel spreadsheet in this case. Over the 3 week project I don’t believe they actually contributed to the content of the list. What was supposed to be a listing of the gaps by area between two processes became a quest to make it such that the excel sheet could be filtered and manipulated such that niche sets of data would align or show patterns. This functionality did not contribute to the project at hand, combine the two processes.

Despite trying to get him to complete the template and move on, he continued to tweak the tool. In the end I resorted to taking one of the iterations of the spreadsheet and working only from that copy, ignoring revisions he had made. By the end of the project I believe I was able to capture all of the gaps and was able to hold the necessary meeting to finalize what must, could and shouldn’t be implemented. This was despite the fact that my list did not have all of the ‘functionality’ of the still evolving spreadsheet.

It is not easy to try to influence people to not get sucked into these constant improvements. Also be careful not to let yourself or your colleagues start to use it as a procrastination tool. “Oh, I’ll start documenting that database with hundreds of fields right after I get this spreadsheet just right.” This is also not good. Big tasks such as data dictionaries are always a pain to get started, but the more you tweak that layout, the more you delay the celebration of no longer having to go through all those line items.

Simply put, what must be done should not be hampered by the lack of sophisticated or niche tools. When there isn’t a deadline breathing down your neck, feel free to start embracing those new best practices or updating the templates.

By JHeep at Seilevel Inc

Do you have comments? Do you want to read more?

Check us out here: http://requirements.seilevel.com/blog/

Is Your Product Knowldege an Asset or Liability?

Seilevel — Wed, 14 Jul 2010 16:19:00 GMT

There was recently an interesting post by John Mansour on the Austin PMM Forum (registration required) discussing whether Product Knowledge was an Asset or Liability to product managers.

The author makes several claims about how product knowledge is a liability:

“In a nutshell, the more product knowledge you have, the less product management you’re doing because your product knowledge gets you sucked in to a plethora of non product management issues.”

“Furthermore, too much product knowledge leads to micro management – the kiss of death for anyone in a leadership role.”

“Detailed product knowledge = liability because you can’t see the forest from the weeds.”

“Detailed product knowledge = liability because it forces you more into ‘how’ features should work instead of ‘what’s needed and why’ from a business perspective.”

“The more you know about your product the more difficult it is to position its true value. “

I have to disagree with Mr Mansour that these are true liabilities, in the sense that the absence of product knowledge doesn’t truly mitigate the liabilities. Good product management is fundamentally about good product management.

It’s your job as a good product manager to avoid running down the ratholes that you could run down as a result of your product knowledge.

Post by MTalbot at Seilevel Inc

check out other blogs here.

Creating Accurate Time Estimates

Seilevel — Fri, 25 Jun 2010 19:45:00 GMT

By Landerson

I recently joined a new project where I will be working as the person responsible for the developing and creating the requirements and documentation on a major development effort. As the person on the hook for a significant portion of work, I need to provide accurate time estimates for my portions of the project. I was concerned about providing accurate time estimates on a new project in a new environment. I am also very aware that deadlines are important and know that if I am unable to accurately estimate my deliveries, I will quickly lose credibility with the rest of the team. Underestimating my deadlines might also put other team members relying on my work at risk of missing their deadlines.

My concerns had me thinking that perhaps others might be in a similar situation. After a bit of research and analysis of my own process I compiled the following list of questions and suggestions to help when making time estimates.

How accurate do your time estimates need to be?
If an estimate needs to be very accurate, it is usually a good idea to take a longer period of time to consider and analyze the answer. It is not unreasonable to ask someone who is looking for a timeline for some “think time” in order to provide an accurate answer. However, when not immediately responding, it is a good idea to communicate a reasonable target for when you will have the estimates finished, even if it’s only 15 minutes of extra think time.
How well do you fully understand the project/tasks that you are being asked to estimate?
If a problem is complex, or if you do not completely understand all of the tasks you need to finish, it will be difficult to make accurate time estimates. Getting as much clarification as you can is necessary. Discussing the details of what you have been asked to accomplish with the person making the request might also provide them insight into the complexity of the request and your work process.
How long has a task of this type taken to accomplish in the past?
It is a good idea to maintain a personal log of tasks and an ongoing list of recorded time spent performing a task. I simply use an excel spreadsheet to record tasks I have finished on my projects and update it when I have a few moments at the end of the day or week. Having a realistic idea of the amount of time I spend on my tasks helps me to accurately predict future projects/tasks.
Are there any assumptions, conditions or constraints which might affect your time estimate?
It is impossible to predict in advance every detail of a project with certainty. It will be important to note your assumptions and constraints when you provide your time estimates to communicate your issues clearly. These could all be considered risks to the accuracy of your time estimate and should continue to be monitored as you begin the tasks/project.
Do you need to add any wiggle room?
You should consider adding contingency time if there is a lot of uncertainty about the tasks or many risks associated with your estimate. By increasing time to the estimate appropriately because a project is new and unfamiliar as a way to prevent underestimating your efforts.
Are there any other elements to the project/tasks that should be included in your time estimate?
One area I consistently forget when creating estimates is the amount of extra time I have to spend doing administrative tasks like organizing meetings, sending emails, or organizing documents. At times, these types of activities are not always predictable, but understanding how much of your work might be effected by other project duties is important. There is a small amount of extra administrative work in most tasks, and adding that into your work estimate will help your estimating efforts.

When I employ these methods they have lead me to more accurate time predictions that have also greatly reduced my anxiety over creating self imposed deadlines that are unrealistic. As I also have an intrinsic desire to please the person asking for my time, using some standard processes in producing my time estimates has lead me to win/win situations for both my project and myself.

You can check out our other blog posts here

How to solve problems?

Karl — Mon, 26 Apr 2010 05:32:00 GMT

As an analyst I almost daily have to solve some kind of problems and I bet you do also. Problems can be in different forms, but I’ve been noticing that the same pattern for finding the solution keeps coming up. I think this pattern is something essential and we use it often but i think it is a good idea to put it on paper.

First, every problem has its parent problem. Yes, EVERY problem! This means that whenever you have a problem you can ask why is it a problem and where it comes from. Consider an alcoholic. Is too much drinking his problem? Probably yes, but there is always the root problem that made him drinking in the first place. Depression maybe?

Now if we forget about alcoholic and think about software development then we can see that the idea stays the same. Our clients are those whose problems we mostly have to solve. For example, if the client comes and says that he needs a button to the user interface.The client has a problem that there is no button currently. This problem has a root problem… maybe the client wants to open a file with this button. The client definitely does not want a button but something else and he/she thinks that the button is going to solve some kind of problem.

We now know that instead of a problem we have a stack of problems. But how can we solve our problem then? The short answer is that we often don’t even have to solve the initial problem. It is OK if we manage to solve one of the root problems. From the previous example, it is fine if we don’t make the button but we manage to do something that the user gets the right information. Or even maybe the user does not get the information but gets the right answer to whatever he/she has to decide automatically. The initial problem is not solved, but the root problem is and we can consider the whole problem solved.

We can also model a process for the problem solving. It makes use of the problem stack and I think I use it very very often. The main idea is that every time the client asks for something, then I analyze two things:

how it could be done
is it relevant

There is always some kind of solution that we may consider the best to this certain problem, but we have to decide two things – is it doable and is it reasonable. The solution is probably not doable if it would take 10 years and too much $$$. If the answer to one of these questions is “no” then we have to move down in the problem stack. We have to focus on the root problem, because the child problem was “unsolvable”.

We have to move to the root problem until we end up with a reasonable and doable solution. This does not mean that we don’t have to think about the root problem before, but by moving down the stack we set our focus to some certain level. It is so easy to solve a problem!

Note that this idea is somewhat connected to the root-cause analysis. Read more about this here: http://www.isixsigma.com/index.php?option=com_k2&view=item&id=1308:&Itemid=49

Karl Blum (karl.blum@gmail.com)
My blog: http://www.karlblum.net/blog/

Quantitative Risk Analysis

Marc Thibault — Mon, 08 Mar 2010 01:56:00 GMT

I may be overreaching but I include risk analysis as a proper subject of systems analysis. I've done enough TRAs to justify that position—at least to myself. So here's a risk analysis topic.

Toying with the idea of getting some certification I took a look at the CISSP and ISC Common Body of Knowledge. One thing I found odd enough to exchange a few emails with ITSec gurus. They assured me that this was the state of the discipline. The offense lay in a particular statement, repeated in various documents:

Purely quantitative risk analysis is not possible because the method is attempting to quantify qualitative items.

That, in the words of Dr. Pauli, is not even wrong; "Nothing that matters is so intangible that it can't be measured," is almost a tautology.

If it matters, it has an effect. Observing that effect is measuring it. Drawing a distinction between its presence or absence is measuring it. Estimating a range of values or probability distribution for it is measuring it.

This isn't unimportant. No one can do a cost/benefit analysis that tells them how much they should spend mitigating a "medium-high risk". The effect is that a lot of people are overspending on security based on a "let's scare the pants off them" qualitative risk assessment.

Bottom line: one of an analyst's skills should be measuring the putatively immeasurable.

Any challenges?